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Abstract 

This report presents a concept for a User Operations Facility (UOF) for 
payloads sponsored by the NASA Office of Aeronautics and Space 
Technology (OAST). The UOF can be located at any OAST sponsored 
center; however, for planning purposes, it is assumed that the center 
will be located at Langley Research Center (LaRC). 

Introduction 

Payload operations on Space Station Freedom will be supported on 
the ground by the Huntsville Operations Support Center (HOSC) at 
Marshall Space Flight Center (MSFC). This responsibility includes 
support for the International Partners as well as NASA users. The 
responsibility encompasses operations planning, on-orbit operations, 
real-time replanning, and post mission review. 

The HOSC will also include an operations facility to accommodate 
Principle Investigators (Pis) who wish to view their data and conduct 
command and control during their experiment. However, this may 
result in long stay times in Huntsville, Alabama, that will be difficult 
and costly for the Pis. Because of this and a need for operations 
continuity, the HOSC is encouraging the NASA user community to 
support experiments from remote User Operations Facilities (UOF) 
and utilize the nationwide communications network for data 
distribution and operations support. In response, the OAST has 



developed a concept that will provide services apropos for 
technology payloads. The facility could be located at any OAST 
sponsored center; however, for planning purposes it is assumed that 
the center will be located at LaRC. 

Purpose 

The conceptual design of an OAST UOF that resulted from two 
meetings with MSFC/Mission Operations Lab personnel is presented 
in figures 1 thru 8. The purpose of this paper is to document the 
meeting results and the associated discussions both for the visibility 
of HOSC personnel and for review by the OAST user community. 

Design Drivers 

For most technology payloads, the data gathered might be 
characterized as data that can be analyzed to understand how 
something acts or how something works. This provides the following 
design drivers: 

1 . Payload data must be delivered to the Pis in a timely 
manner and in a useful format. 

2. Ancillary data must be sufficient to enable the analyst to 
identify and eliminate false results. 

3. Archival data must be stored to support future 
research. 

With a few exceptions Technology payloads will not require that data 
be observed in real-time (seconds). However, to allow rescheduling 
or replanning in response to data quality or unexpected results, the 
payloads will need to receive data in near-real time (up to 1-day). 
Distributing data in near-real-time rather than real-time enables two 
design drivers: 

4. Around-the-clock operations to support technology 
payloads is not a requirement. 

5. Payloads that require real-time data can be supported 
by exception at the US Operations Center (USOC located at 
MSFC), or at the UOF located at LaRC, or if the data window is 
short term, by NASCOM transmission to the PI at a remote site. 
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A requirement for the UOF to provide experiment analysis for an 
individual payload has not been identified. This enables the 
following two drivers: 

6. Analysis services by the UOF can be limited to evaluation 
of communication system quality and the payload environment 
on-board. 

7. The UOF will participate in problem analysis (and 
solution) on a "System" level and depend upon the payload for 
analysis of payload performance. 

Discussion of UOF Concept 

Figures 1 through 8 present a concept for a UOF to support 
technology payloads sponsored by OAST. The figures have been 
discussed with MSFC personnel. The concept characterizes a UOF 
which is an extension of the HOSC at MSFC and thereby facilitates 
plans by the Program to support payloads. 

The first figure shows the path of mission planning data and mission 
operations data to the UOF. Payload data and video (and ancillary 
data) from the SSF will be down linked by way of the TDRSS Ku band 
and received at both the HOSC at MSFC and the SSCC at JSC. The UOF 
will receive operations data via the HOSC and video via the SSCC. The 
HOSC will also host a database for all user related mission planning. 

In summary, the HOSC and the SSCC will act as the operations 
interface between the SSF Program and the users (Payloads). This 
plan has been incorporated into the concept presented herein 
without any exceptions. Also, since the data will be delivered from 
the SSF unaltered, even encrypted data, if needed, will not present 
an issue. 

Figure 2 illustrates how the UOF will work with the Payload 
Operations Integration Center (POIC). The POIC is a facility within 
the HOSC which will be the management and information center for 
mission planning and mission operations. To plan the mission, to 
change mission plans, or to support activities on-board the SSF, the 
UOF will work directly with the POIC. 

Mission planning will include mission development activities such as 
payload initialization procedures, payload operations procedures. 
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crew procedures, and simulation exercises. The UOF will also develop 
changes during the mission with the POIC. Such changes may include 
new uplink commands, revised schedules or procedures or changes 
to on-board software. Changes which must be transmitted to the SSF 
will be planned with the POIC and transferred to the SSCC for uplink, 
as shown in the figure, via the TDRSS S-band. 

Similar to the presentation in figure 1, figure 2 describes the 
operations interface between the SSF Program and the user. This 
plan has been incorporated into the concept presented herein 
without any exceptions. 

Figure 3 completes the effort to characterize the operations interface 
between SSF Program and the user community. The Program will 
provide one user facility, the United States Operations Center (USOC), 
at the HOSC for Pis who wish to support a mission from MSFC. For all 
other users the SSF Program perimeter is the delivery of data to the 
users as depicted by the gray area in the figure. The user may be a 
UOF as described herein, or it may be a remote terminal at a PI 
location (direct communication not shown), or it may be a 
communication Gateway which is the interface with an international 
partner. An issue, which will be clarified below, is whether the HOSC 
has the responsibility to deliver data to the communications network 
or to the UOF. The difference is the cost of the communications 
medium (lines). 

Figure 4 shows the concept for a UOF that resulted from discussions 
with MSFC operations personnel. The UOF facility includes a network 
interface, a workstation, a file server and database, a terminal for 
visiting Pis, and a terminal to handle off-line services. The network 
interface will receive transmissions from MSFC over a T-l line, and 
direct the data to the UOF facility. The capability of the T-l line is 
1.55 Megabit/sec. The workstation will be set up to manage data 
throughput and support UOF services. The workstation will be the 
primary terminal for housekeeping and for coordination with the 
HOSC. The file server will provide short-term and archival storage 
and be the source for retransmission of data to PI terminals, both 
local and remote. 

A terminal will be available for Pis who wish to support a mission 
from the UOF. This will be particularly beneficial for payloads which 
require ground support during the execution of an experiment by the 
crew. The PI will be able to view data as it is received and be able to 
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respond to questions as they occur. The service desk will have a 
terminal to respond to questions from remote Pis and to work with 
remote Pis when problems or changes require attention. 

Pis will access stored data either directly from the HOSC or from the 
UOF. It is expected that the need for real-time data will be the 
exception and that normal data needs will be satisfied from data 
storage. The HOSC will provide short term storage, the UOF will 
provide short-term and long term storage. 

Figure 5 shows how the facility in Figure 4 will be implemented. The 
UOF provides a service to the SSF Program as an interface between 
the HOSC and the individual payload Pis. In this context the UOF is 
an extension of the HOSC with similar functions as the USOC, i.e.., to 
accommodate users. Indeed, operationally, the UOF and the USOC are 
very similar. This was recognized early in the conceptual design 
effort and was a useful parameter in the development of a UOF for 
technology payloads. 

A T-l line to LaRC that can be available for SSF mission support is 
not available at this time. This will be a leased line. Whether this 
line will be provided by the Program or by the UOF has been 
identified as an issue. The network interface will utilize the NASA 
network at LaRC with addition of equipment as necessary (an 
additional deblocker). The workstation will be a copy of the user 
workstation designed for the USOC. By copying the USOC 
workstation, the UOF realizes a secondary benefit, i.e., much of the 
software that is designed for the USOC will be applicable for the UOF 
also. In addition, MSFC has offered design support to implement the 
workstation. Data files for short-term and long-term storage will be 
implemented to the extent possible in database equipment available 
at LaRC. 

The size of the UOF facility is estimated for the following 
accommodations: a workstation, two desk top terminals for Pis, a 
services desk and terminal, a storage system to archive data, and a 
conference table with chairs, conference phone and vuegraph 
projector. The UOF is not a large facility, perhaps the space 
equivalent of about three offices. 

Figure 6 is included to show one option of how the UOF may be 
managed. The figure shows OAST Sponsor functions in four 
categories; direct support to the Payloads, interface activities to 
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coordinate the Payload and the Program, activities which qualify the 
payload for flight, and activities which prepare for operations. 
Because the sponsor is an "Unofficial" function, these activities 
support the Payload as a friend rather than as a representative of 
the Program. It is in this context that a UOF is proposed which can 
provide services for OAST payloads. Personnel will supply skills to 
(1) operate the facility, (2) provide mission interface services for the 
payloads, and (3) support the planning, reconfiguration and mission 
readiness functions. Figure 6 is intended to illustrate that the UOF 
can be managed in such a manner that its charter will be continually 
justified by services provided. 

Figure 7 & 8 are the short-term schedule and long-term milestones. 
The short-term schedule is tentative because of review of the 
Program schedule for the HOSC. The long-term milestones support 
the goal of an operational UOF in 1997. 

Issues and Recommendations: 

Issue 1: The key issue before all others is whether to provide a UOF 

for technology payloads. Certainly it is not unreasonable for Pis to 
retrieve data from the USOC and it may not be unacceptable for a PI 
to travel to the USOC when real-time support is needed. It may be 
more difficult to respond to experiment problems from a remote 
location if HOSC personnel are barely familiar with the payload and 
the PI. And considerable lost time and expense may result if the PI 
isn't familiar with the HOSC process for initiating and verifying 
changes during a mission. Similarly, a new group of Pis will work 
with the HOSC to plan operations for each mission, thus, it may 
require considerable expense for the HOSC to train the new Pis in the 
flight readiness process. 

Recommendation: The advantages of having skilled personnel 

to help the Pis through the operations process, along with the 
desire to have a data archive for future research, plus the need 
to encourage technology research in space and "make it easy", 
are offered as justification for a UOF for technology payloads. 

It is recommended, therefore, that the development of a UOF 
be continued. 

Issue 2: An archive of data collected by technology payloads in 

space should be managed as a national resource. The archive should 
be cataloged to enable future investigators to research an experiment 
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for particular information and should include sufficient ancillary data 
to enable a thorough understanding of experiment conditions. The 
archive system should be useful to the technology community to 
avoid the need to recreate an experiment again. 

Recommendation: Develop an archive system at the UOF to 

ensure accessibility and usefulness of SSF technology 
experiment data. 

Issue 3: Two design drivers (4&5) for the UOF concept are that the 

technology payloads will not require around-the-clock support and 
those payloads that do require on-line, real time support can be 
handled as exceptions. An issue which results is how the UOF can be 
operated on a normal workday schedule and coordinate operations 
with the HOSC which will be operated around-the-clock. 

Recommendation: Plan for the UOF to support operations 

on an eight hour workday schedule. Identify impacts related 
to onboard scheduling and overtime support required by 
technology payload experiments. 

Issue 4: Payloads will supply operations requirements in the 

Payload Integration Agreement (PIA) and operations data in the PIA 
Annexes. MSFC Operations personnel are expecting to perform initial 
mission planning on the basis of these documents without payload 
involvement. If Program personnel can perform this initial planning 
without involving the payloads it will realize a considerable cost 
savings to the payloads. The issue is the level of involvement of UOF 
(or OAST) necessary to effectively implement this system. 

Recommendation: Continue to participate in the development 

of the PIA and PIA Annexes blank books to assure that the 
information supplied by the payloads will enable the Program 
to plan payload operations. 

Issue 5: The program has chosen to interpret the communications 

perimeter as the input to the data distribution network. Thus, the 
Program has not accepted the cost of data communication to LaRC. 

Recommendation: Continue to press for the SSF Program to 

deliver payload operations data to the UOFs and bear the cost 
of data transmission (a T-l data line to LaRC). 
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Issue 6: An effort is underway by MSFC operations personnel to 

identify ancillary data needed by the payload community. This data 
will be distributed as a communications packet. An issue for the UOF 
is identification and storage of ancillary data that is necessary to 
support analysis of payload data. 

Recommendation: Analyze this issue with the viewpoint that 

ancillary data that is necessary for the analysis of experiment 
results is payload data and will be related and archived as 
payload data. 

Concluding Remark s 

1. The UOF facility presented herein will provide services 
appropriate for technology payloads. It will facilitate planning and 
support Pis during experiments on-board the SSF. An effort to 
develop the design of a UOF for technology payloads is felt to be 
worthwhile. 

2. The cost of a facility which reflects the concept presented will 
take advantage of several factors: 

The network interface will add a few equipment items to the 
local network at LaRC. 

The cost of a T-l line is an issue. 

The workstation can be the same as the workstation being 
designed for the USOC. 

The software for the workstation can copy the software being 
designed for the USOC. 

The UOF may be able to piggy-back data storage and data 
archives on equipment available at LaRC. 

The UOF can be managed as an additional OAST function. 

The UOF personnel can be selected for skills needed. 

If the design of the UOF takes advantage of these factors, then the 
cost of a UOF for technology payloads will indeed be modest. With 
that in mind it is worthwhile to continue to pursue a UOF design 
within the guidelines and schedules of the concept presented herein. 
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UOI-FCD - 4.1.6 - 'The POIC supports all PL operations whether 
performed by the flight crew or by UOF personnel." 
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FIGURE 3 - SSFP PERIMETER OF RESPONSIBILITY 



UOI-FCD Draft - 5.1.2 - "Code O shall develop and maintain the 
Comm capabilities between the POIC and U.S. user operations 

facilities, necessary to support PL operations and the comm 

capabilities required to support mission planning." 
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FIGURE 4 - DATA DISTRIBUTION - OVERVIEW 
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FIGURE 5 - FACILITY IMPLEMENTATION 
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FIGURE 6 - OAST SPONSOR - SCOPE 
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A UOF which is adequate to support OAST PLs can be 
managed as an added SSUO "Code R Sponsor 1 ' service. 
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FIGURE 7 - UOF CONCEPT DEVELOPMENT 


FACILITY CONCEPT 

> June 30, 92 » Initial Concept of UOF for LaRC 

> Aug 31, 92 » Concept for Requirements on POIC 

> Oct 31 , 92 » Concept for User Data Processing 

> Mar 31 , 93 » Concept Cost Breakdown. 
PROPOSAL DEVELOPMENT 

> Mar 31, 93 » OAST UOF Mission Operations Plan 

> July 31 ,93 » OAST UOF Proposal 
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FIGURE 8 - UOF CONCEPT DEVELOPMENT 

COMMENTS: 

Milestones leading to fuilup operations are as follows: 

> Dec 31, 93 » OAST Approval 

> Mar 31, 94 » OAST UOF Funding Plan 

> Oct 1 , 94 » Long Lead Funding 

> Oct 1,95 » Installation and Test Funding 

> Oct 1 , 96 » Initial Ops Funding 

> Oct 1, 97 » Full Ops Funding 
ISSUES: 

During initial operations in 1997 the OAST UOF will be 
operated redundantly to the USOC. The facility will 
be brought on-line independently as it is proven. 
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